1. Field of the Invention
The present invention relates to a data storage virtualization subsystem, and in particular, to a data storage virtualization subsystem providing at least one physical storage device (abbreviated PSD) pool formed by at least one PSD.
2. Description of the Related Art
Storage virtualization is a technology to virtualize physical storage by combining sections of physical storage devices (abbreviated PSDs), physical devices whose primary function it is to store data into logical storage entities, herein referred to as logical media units (LMUs) whose individual storage elements (e.g. storage blocks) are uniquely addressable by a logical storage address to make LMUs accessible to a host entity. Examples of PSDs are hard disk drives (abbreviated HDD), storage tapes, compact disk drives, etc. This technology has been used primarily in redundant array of independent disks (RAID) storage virtualization, which combines smaller PSDs into larger volume, fault tolerant, or higher performance LMUs.
A data storage virtualization subsystem (SVS) comprises at least one storage virtualization controller, abbreviated SVC, and at least one PSD connected thereto to provide LMUs to a host entity for large data storage therefor to execute the IO operations in response to the IO requests issued by the host entity to get the data stored in the PSDs corresponding to the LMU addresses. The primary purpose of the SVC is to map combinations of sections of PSDs to LMUs visible to a host entity, and to present each LMU to the host entity as if it were a directly connected PSD of which the LMU is supposed to be the logical equivalent. In order to accomplish this, IO requests sent out by the host entity to be processed by the SVC that would normally generate certain behavior in an equivalent PSD also generate logically equivalent behavior on the part of the SVC in relation to the addressed LMU. The result is that the host entity “thinks” it is directly connected to and communicating with a PSD while in actuality is connected to the at least one SVC that is simply emulating the behavior of the PSD of which the addressed LMU is the logical equivalent.
An external (sometimes referred to as “Stand-alone”) storage virtualization controller is a storage virtualization controller (SVC) that connects to the host entity via an IO interface and that is capable of supporting connection to devices that reside external to the host entity and, in general, operates independently of the host entity. An example of an external SVC is an external, or stand-alone, direct-access RAID controller. A RAID controller combines sections on one or multiple physical storage devices (PSDs), the combination of which is determined by the nature of a particular RAID level, to form logical media units (LMUs) that are contiguously addressable by a host entity to which the LMUs are made available. A single RAID controller will typically support multiple RAID levels so that different LMUs may consist of sections of PSDs combined in different ways by virtue of the different RAID levels that characterize the different LMUs.
Another example of an external SVC is a JBOD emulation controller. A JBOD, short for “Just a Bunch of Drives”, is a set of PSDs that connect directly to a host entity via one or more IO device interconnects. A further example of an external SVC is a controller for an external tape backup subsystem.
It is straight to understand that the more PSDs an SVS provides, the higher possibility the SVS encounters a failed PSD. For a LMU configured to have redundant data and to support data rebuilding function, when a member PSD of the LMU is failed, the LMU will enter a “degraded mode”, which means that the LMU is under a situation of lower data integrity protection than that of a normal situation. The data rebuilding function will be triggered if a spare PSD is available. If there is not any spare PSD for data rebuilding in the SVS, users need to stop the whole system to replace the failed PSD to keep the LMU in a normal state rather than in a degraded mode. In the present specification, the PSDs used for storing user data or associated redundant data are referred to “normally-used PSDs”, and the PSDs used as substitutes for normally-used PSDs are referred to “spare PSDs”. In the viewpoint of economic efficiency, in an SVS having a fixed number of PSDs, the less PSDs are designated as spare PSDs, the higher storage capacity for storing user data and associated redundant data is, and so is the economic efficiency of the SVS. However, the more normally-used PSDs a spare PSD is to support, the lower possibility a normally-used PSD can be supported by the spare PSD when needed because of the higher chance that the spare PSD might have been used as a normally-used PSD in place of another normally-used PSD failed earlier. A conventional solution for such a situation is to provide a type of “global spare PSD” to supply backup capability to all LMUs within an SVS. Another conventional solution is to provide a type of “local spare PSD” to supply backup capability to a specific LMU, and we call such characteristic of a local spare PSD is “dedicated”.
FIG. 1 shows an exemplary solution of spare physical storage devices of SVS in the prior art, wherein the data storage virtualization subsystem (SVS) 20 comprises a storage virtualization controller (SVC) 100 and a plurality of physical storage devices (PSDs) 130-1 to 130-24 connected to the SVC 100. In the present embodiment, the SVC 100 and the PSDs 130-1˜130-8 are received in an enclosure 120-1, the PSDs 130-9˜130-16 are received in an enclosure 120-2, and the PSDs 130-17˜130-24 are received in an enclosure 120-3. The enclosure 120-2 is connected to the enclosure 120-1 through an expansion port through which PSDs in other enclosures are allowed to be connected thereto. The PSDs depicted by solid lines represent the normally-used PSDs, and the PSDs depicted by dashed lines represent spare PSDs. The logical media unit (LMU) 140-1 comprises the normally-used PSDs 130-1, 130-2, 130-9, 130-10, and 130-17, and is provided with a local spare PSD 130-7. The LMU 140-2 comprises the normally-used PSDs 130-3, and 130-4 and is provided with a local spare PSD 130-8. The LMU 140-3 comprises the normally-used PSDs 130-11, 130-12, 130-18, 130-19, and 130-20, and is provided with a local spare PSD 130-23. The LMU 140-4 comprises the normally-used PSDs 130-5, 130-6, 130-13, 130-14 and is provided with a local spare PSD 130-15. The LMU 140-5 comprises the normally-used PSDs 130-21 and 130-22 and is provided with a local spare PSD 130-24. In addition, a global spare PSD 130-16 is provided to the SVS 20. A local spare PSD is a spare PSD dedicated to the PSDs of a designated LMU; that is, when needed, the local spare PSD can be a substitute for any of the PSDs belonging to the designated LMU. For example, the local spare PSD 130-7 of LMU 140-1 is dedicated to all the normally-used PSDs of LMU 140-1, i.e., the PSDs 130-1, 130-2, 130-9, 130-10, and 130-17, and when necessary, PSD 130-7 can be used as a substitute for any of the PSDs 130-1, 130-2, 130-9, 130-10, and 130-17. On the other hand, the global spare PSD 130-16 supplies backup capability to all the normally-used PSDs 130-1˜130-6, 130-9˜130-14, and 130-17˜130-22 of all LMUs 140-1˜140-5 within the SVS 20, that is, when needed, the global spare PSD 130-16 can be a substitute for any of the PSDs belonging to the SVS 20.
One or more of the normally-used PSDs and spare PSDs 130-1˜130-24 have a configuration information inside. The configuration information of a PSD may comprise the information associated with the LMU, or the recording of the spare status of the PSD if the PSD is designated as a spare PSD, wherein the spare status indicates that the PSD is either a local spare PSD or a global spare PSD. The configuration information of PSD(s) is stored in the memory (not shown) of the SVC 100 when the SVS 20 is switched on. The stored configuration information is then used to reflect the relationship between all the LMUs and spare PSDs for the SVC to identify the PSDs to which a spare PSD supplies backup capability.
However, these two types of conventional spare PSD definitions are not flexible enough because the serving range of a spare PSD can only be defined to either a specific LMU or the whole SVS.